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Abstract 


In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node 
(MN) is assigned with a Home Network Prefix (HNP) during its initial 
attachment, and the MN configures its Home Address (HoA) with the 
HNP. During the movement of the MN, the HNP remains unchanged to 
keep ongoing communications associated with the HoA. However, the 
current PMIPv6 specification does not specify related operations when 
HNP renumbering has occurred (e.g., due to change of service provider 


or site topology, etc.). In this document, a solution to support HNP 
renumbering is proposed, as an optional extension of the PMIPv6 
specification. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8191. 
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1. Introduction 


At the time of writing, network managers prefer Provider-Independent 
(PI) addressing for IPv6 to attempt to minimize the need for future 
possible renumbering. However, a widespread use of PI addresses will 
cause Border Gateway Protocol (BGP) scaling problems [RFC7010]. It 
is thus desirable to develop tools and practices that make IPv6 
renumbering a simpler process to reduce demand for IPv6 PI space 
[RFC6879]. In this document, we aim to support HNP renumbering when 
the HNP in PMIPv6 [RFC5213] is not a PI prefix. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in BCP 
14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


2. Usage Scenarios 


There are a number of reasons why HNP renumbering support in PMIPv6 
is useful, and some scenarios are identified below: 


Scenario 1: the HNP set used by a PMIPv6 service provider is 
assigned by a different Internet Service Provider (ISP), 
and then HNP renumbering MAY occur if the PMIPv6 service 
provider switches to a different ISP. 


Scenario 2: multiple Local Mobility Anchors (LMAs) MAY be deployed 
by the same PMIPv6 service provider, and then each LMA 
MAY serve for a specific HNP set. In this case, the HNP 
of an MN MAY change if the serving LMA is changed to 
another LMA that does not inherit the assigned HNP set 
[RFC6463]. 


Scenario 3: PMIPv6 HNP renumbering MAY be caused by the rebuilding 
of the network architecture as the companies split, 


merge, grow, relocate, or reorganize. For example, the 
PMIPv6 service provider MAY reorganize its network 
topology. 


In Scenario 1, we assume that only the HNP is renumbered, while the 
serving LMA remains unchanged; this is the basic scenario considered 
in this document. In Scenarios 2 and 3, more complex situations MAY 
result; for example, HNP renumbering MAY occur due to the switchover 
of a serving LMA. 
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In the Mobile IPv6 (MIPv6) protocol, when an HNP changes, the Home 
Agent (HA) will actively notify its MN about the new prefix, and then 
the renumbering of the Home Network Address (HoA) can be well 
supported [RFC6275]. In basic PMIPv6, the PMIPv6 binding is 
triggered by a Mobile Access Gateway (MAG), which detects the 
attachment of the MN. A scheme is also needed for the LMA to 
immediately initiate the PMIPv6 binding state refreshment during the 
HNP renumbering process. Although this issue is also mentioned in 
Section 6.12 of [RFC5213], the related solution has not been 
specified. 


3. HNP Renumbering Procedure 
When HNP renumbering happens in PMIPv6, the LMA MUST notify the MAG 
about the new HNP, and then the MAG MUST announce the new HNP to the 
attached MN accordingly. Also, the LMA and the MAG MUST update the 
routing states for the HNP and the related addresses. To support 
this procedure, [RFC7077] can be adopted; it specifies an 
asynchronous update from the LMA to the MAG about specific session 
parameters. This document considers the following two cases: 


(1) HNP is renumbered under the same LMA 


In this case, the LMA remains unchanged as in Scenarios 1 and 3. 
The steps are shown in Figure 1. 


<----- RA/DHCP -------- | 


| 

| 

| 

| | 
| | 
| | 

Address configuration | 

| Update binding & routing states | 
| | 
| | 
| | 
| 

| 


| Update binding & routing states 


Figure 1: Signaling Call Flow for HNP Renumbering 
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o When a PMIPv6 service provider renumbers the HNP set under the 
same LMA, the serving LMA SHOULD initiate the HNP renumbering 
operation. The LMA allocates a new HNP for the related MN. 


o The LMA sends the Update Notification (UPN) message to the MAG 
to update the HNP information. If the Dynamic Host 
Configuration Protocol (DHCP) is used to allocate the address, 
the DHCP infrastructure MUST also be notified about the new 
HNP. 


o Once the MAG receives this UPN message, it recognizes that the 
related MN has the new HNP. Then, the MAG MUST notify the MN 
about the new HNP with a Router Advertisement (RA) message or 
allocate a new address within the new HNP through a DHCP 
procedure. 


o After the MN obtains the HNP information through the RA 
message, it deletes the old HoA and configures a new HoA with 
the newly allocated HNP. 


o When the new HNP is announced or the new address is configured 
to the MN successfully, the MAG MUST update the related 
binding and routing states. Then, the MAG sends back the 
Update Notification Acknowledgement (UPA) message to the LMA 
for the notification of successful update of the HNP, related 
binding state, and routing state. Then, the LMA updates the 
routing and binding information corresponding to the MN in 
order to replace the old HNP with the new one. 


(2) HNP renumbering is caused by the LMA switchover 


Since the HNP is assigned by the LMA, HNP renumbering MAY be 
caused by the LMA switchover, as in Scenarios 2 and 3. 


The LMA information is the basic configuration information of the 
MAG. When the LMA changes, the related profile SHOULD be updated 
by the service provider. In this way, the MAG initiates the 
binding registration to the MN’s new LMA as specified in 
[RFC5213]. When HNP renumbering is caused in this case, the new 
HNP information is sent by the LMA during the new binding 
procedure. Accordingly, the MAG withdraws the old HNP of the MN 
and announces the new HNP to the MN, similar to the case when the 
HNP is renumbered under the same LMA. 
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4. Session Connectivity 


HNP renumbering MAY cause the disconnection of the ongoing 
communications of the MN. Basically, there are two modes to manage 
the session connectivity during HNP renumbering. 


(1) Soft mode 


The LMA will temporarily maintain the state of the old HNP 
during the HNP renumbering (after the UPA reception) in order to 
redirect the packets to the MN before the MN reconnects the 
ongoing session and notifies the Correspondent Node (CN) about 
its new HoA. This mode is aiming to reduce packet loss during 
HNP renumbering, but the binding state corresponding to the old 
HNP SHOULD be marked, for example, as transient binding 
[RFC6058]. Also, the LMA MUST stop broadcasting the routing 
information about the old HNP if the old HNP is no longer 
anchored at this LMA. 


(2) Hard mode 


If HNP renumbering happens with the switchover of the LMA, hard 
mode is RECOMMENDED to keep the protocol simple. In this mode, 
the LMA deletes the binding state of the old HNP after it 
receives the UPA message from the MAG, and the LMA silently 
discards the packets destined to the old HNP. 


5. Message Format 
(1) UPN message 


In the UPN message sent from the LMA to the MAG, the 
notification reason is set to 2 (UPDATE-SESSION-PARAMETERS) . 
Besides, the HNP Option [RFC5213] containing the new HNP and the 
Mobile Node Identifier Option [RFC4283] (which identifies the 
MN) are contained as Mobility Options of UPN. The order of the 
HNP Option and Mobile Node Identifier Option in the UPN message 
is not mandated here. 


(2) UPA message 


The MAG sends this message in order to acknowledge that it has 
received an UPN message with the (A) flag set and to indicate 
the status after processing the message. If the MAG did not 
successfully renumber the HNP, which is required in the UPN 
message, the UPA message has the Status Code set to 128 (FAILED- 
TO-UPDATE-SESSION-PARAMETERS), and the subsequent operation of 
the LMA is PMIPv6 service provider specific. 
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6. 


(3) RA message 


When the RA message is used by the MAG to advise the new HNP, it 


contains two Prefix Information Options [RFC4861] [RFC4862]. In 
the first Prefix Information Option, the old HNP is carried, and 
the related Preferred Lifetime is set to 0. In the second 


Prefix Information Option, the new HNP is carried with the Valid 
Lifetime, and Preferred Lifetime set to larger than 0. 


(4) DHCP message 


When the DHCP is used in PMIPv6 to configure the addresses for 
the MN, new IPv6 address or addresses (e.g., the HoA) will be 
generated based on the new HNP, and the related DHCP procedure 
is also triggered by the reception of the UPN message [RFC3315]. 


Other Issues 


In order to maintain the reachability of the MN, the Domain Name 
System (DNS) resource record corresponding to this MN MAY need to be 
updated when the HNP of the MN changes [RFC3007]. However, this is 
beyond the scope of this document. 


Security Considerations 


The UPN and UPA messages in this document MUST be protected using 
end-to-end security association(s) offering integrity and data origin 
authentication as specified in [RFC5213] and [RFC7077]. 


When HNP renumbering is triggered, a new HNP SHOULD be allocated to 
the MN. The LMA MUST follow the procedure of PMIPv6 to make sure 
that only an authorized HNP can be assigned for the MN. In this way, 
the LMA is ready to be the topological anchor point of the new HNP, 
which is for that MN’s exclusive use. 


Per [RFC4862], if the Valid Lifetime in a Prefix Information Option 
is set to less than 2 hours in an unauthenticated RA, it is ignored. 
Thus, when the old HNP that is being deprecated is included in an RA 
from the MAG, the Valid Lifetime SHOULD be set to 2 hours (and the 
Preferred Lifetime set to 0) for an unauthenticated RA. However, if 
the legality of the signaling messages exchanged between MAG and MN 
can be guaranteed, it MAY be acceptable to also set the Valid 
Lifetime to 0 for an unauthenticated RA. 


IANA Considerations 


This document does not require any IANA actions. 
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